home *** CD-ROM | disk | FTP | other *** search
- This little program fixes two bugs I found in cdtv's file system (cdfs.library)
- It only works for cdfs v24 rev 9; it won't do anything if you don't have that
- version of cdfs. It has only been tested on my unaccelerated a500 w/ a570,
- v2.0 OS (should work with 1.3, though). If you have any comments or questions,
- I can be reached via internet email as dark@judy.indstate.edu.
-
- To run, just type
- run >nil: cdfix
- on your cdtv or a500 w/ a570 sometime before you insert a disk which would
- otherwise make it crash :)
-
- -- description of bugs --
-
- Problem 1 [direct transcript of my post to comp.sys.amiga.programmer]
- As you probably know, the A570 and CDTV have problems reading non-CDTV
- ISO-9660 disks [those that I have tried and read by other means are AB20 and
- the OS/2 Devel. Kit. After looking throught the ROM on my A570 over the last
- couple of days, I found what I believe to be the problem. Of course since
- it's in ROM, I have no fix as yet, but I just thought I'd let you all know &
- see what you think. The problem is in cdfs (CD0:/cdfs.library), and the
- following refers to cdfs 24.9 (22.10.91) @ $f35544.
-
- The problem is after $f3654c:
-
- $f3654c tst.l -4(A5)
- bne $f36558
- move.l D4,-4(A5)
- $36558 ...
-
- Which I believe should read:
-
- $f3654c tst.l -4(A5)
- bne $f36558
- move.l D4,D0
- add.l D6,D0
- move.l D0,-4(A5)
- $36558 [not any more :)] ...
-
- Of course fixing the problem in ROM would be relatively easy if I were
- inclined to burn my own, since there are plenty of inefficient pieces of
- code even immediately surrounding the offensive code that the addition of 4
- bytes could be offset, for instance, by making a few bra.w xxx into bra.s
- xxx in the near vicinity.
-
- To better explain the bug: The routine @ $F36464 checks the disk for
- ISO-9660 descriptors. In the routine, a buffer is allocated (A3 = "buf")
- which contains sectors from the disk. D4 ("i") keeps track of the number of
- the first sector in the buffer, and D6 ("j") keeps track of the offset into
- the buffer currently being on. (D5 ("o") is D6*2048, or the actual
- byte-offset into the buffer). -4(A5) ("vold") stores the volume descriptor
- when found.
-
- [Note: all iso struct names are from the "ctools" utility on ftp.cdrom.com]
-
- There is a loop similar to:
-
- /* irrelevant bs.. */
- /* decl buf as struct iso_volume_descriptor *buf */
- /* allocate buf = nsecs*2048 bytes; nsecs = 16 or 2 dep. on avail. mem. */
- for(i=16;i<256;i+=nsecs) {
- dbprint3("\tp%lx.%lx\n",i,vold);
- readcd(buf,i,nsecs); /* read nsecs sectors starting @ i */
- for(j=0,o=0;j<nsecs;j++) { /* isiso: check for CD001 v1 */
- if(isiso(buf[j])) switch(buf[j].id) {
- case 0:
- /* irrelevant CDTV stuff */
- break;
- case ISO_VD_PRIMARY: /* @ $f3654c */
- if(!vold)
- vold = i; /* should be vold = i+j; */
- if(!memcmp(buf[j].data,'CDTV'+spaces,32||..)
- more irrelevant CDTV stuff;
- break;
- case ISO_VD_END:
- j = nsecs;
- i = 256;
- break;
- }
- }
- }
- /* yet more irrelevant bs */
-
- Well, there you have it. Simple error when assigning vold as commented..
- Folks at Commodore: How about either fixing it or telling me why this isn't
- a bug?
-
-
- Problems 2&3: [again, direct transcript from my post]
-
- Well, I finally got around to making a patch which fixed the bug I mentioned
- in the previous posting, and discovered several new problems, among which is
- the fact that the bug I reported is not the "real" bug [i.e. the one making
- cdfs crash].
- The problems are as follows:
- 1) When cdfs interprets the date, it does the following: [dis output]
- RF38632
- movem.l D2/A2,-(SP)
- move.l $0C(SP),A2
- move.l $10(SP),A1
- moveq #4,D1
- bsr RF386BA
- tst.w D0
- beq.s lF38662
- sub.w #$076C,D0
- move.b D0,(A2)+
- moveq #4,D2
- lF38650
- moveq #2,D1
- bsr RF386BA
- move.b D0,(A2)+
- dbra D2,lF38650(PC)
- clr.b (A2)+
- movem.l (SP)+,D2/A2
- lF38662
- rts
-
- Note that when there is not a valid date, it returns via lF38662, which
- should have been moved up one line, and thus causes rts to crash cdfs/the
- system... This is what causes AB20 to crash, as my patch verified after I
- fixed this bug.
-
- 2) When cdfs reads [via cdtv.device, of course] the disk looking for the
- root node, it keeps track of where it found one [see previous bug
- posting], and continues searching for a CDTV-specific block (boot block?
- 31-char filename dir? who knows?). Then when it doesn't find a
- CDTV-specific block, it re-reads the disk for the previously-tagged root
- block. This read returns an error of -10 90% of the time on my A570 for
- my two non-CDTV 9660 disks, and is the reason the OS/2 developers' disk
- couldn't be read. Anybody have any idea what error -10 is, and/or how to
- fix the bug? [the solution I'm attempting at the moment involves just
- copying the sector into the buffer when it finds it rather than
- re-reading it]
-
- Ah, well. If I ever get this horrible patch to install itself directly from
- disk instead of only from within the debugger (why? I haven't a clue - it
- doesn't matter if I single-step or not, it just works from within the
- debugger - probably due to some messaging conflicts), and to fix that error
- -10 bug, maybe I'll upload the patch to aminet or boing... [done]
-
- -------------------------
-
- I also included cdfs.sym, which is a set of symbols you can use to
- disassemble cdfs yourself if you so desire and cdfs is located @ $f35544.
-
- -----------------------------------------------------------------------------
- Thomas J. Moore, Amiga Programmer | Parallel Processing: The future of PC's
- inet: dark@judy.indstate.edu | Must .... Kill .... Bugs.... AAARRRGGHHH
- -----------------------------------------------------------------------------
-